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1.  Introduction 


DARPA  has  supported  research  in  fonnal  verification  for  many  years  (see  MacKenzie’s 
book  for  an  interesting  history  of  how  ARPA  helped  get  this  field  started  in  the  1960s  and 
70s  [MacKenzie  2001]).  But  formal  verification  has  sometimes  been  criticized  for  a  long 
list  of  shortcomings:  it’s  too  expensive  to  do;  people  don’t  verily  the  actual  engineered 
systems  but  just  simplistic  abstractions  of  the  real  world;  fonnal  proofs  of  real  systems 
are  too  big  to  check  for  errors;  and  so  on.  These  criticisms  cannot  be  lightly  dismissed. 
What  we  set  out  to  do  in  our  DARPA-supported  research  was  to  apply  fonnal  verification 
in  settings  that  can  address  these  criticisms  directly. 

We  chose  two  main  problem  domains:  Language-based  security  for  virtual  machines, 
and  distributed  authentication  frameworks.  For  each  problem  domain,  I’ll  explain  what  is 
the  problem  that  motivates  the  need  for  formal  verification,  why  it  seemed  that  formal 
methods  might  actually  be  useful  in  this  domain,  and  what  solutions  we  engineered. 

2.  Language-based  security  for  virtual  machines 

Component-software  platforms  such  as  Sun’s  Java  and  Microsoft’s  .Net  are  increasingly 
used  by  commercial  software  developers  because  they  provide  many  advantages  over 
conventional  development  (in  languages  such  as  C  and  C++).  Commonly  accepted 
software-engineering  practices  such  as  data  encapsulation  (information  hiding)  are 
enforceable  on  these  platforms,  in  contrast  to  C/C++  where  careless  programmers  can 
bypass  infonnation-hiding  rules.  This  brings  many  benefits:  software  development  is 
quicker  and  software  is  more  reliable.  There  are  important  security  benefits  as  well:  Java 
programs1  are  basically  immune  to  buffer-overrun  vulnerabilities,  which  is  the  most 
common  path  that  attackers  use  to  subvert  software  on  the  Internet  today. 

Because  modem  programming  languages  such  as  Java  provide  better  support  for  reusable 
components  than  previous-generation  languages,  commercial  developers  often  build  their 
software  from  a  combination  of  off-the-shelf  and  custom-built  components.  Often  the 
off-the-shelf  components  are  obtained  from  other  parties.  This  leads  to  many  efficiencies 
in  building  lower-cost  and  more  reliable  software;  but  it  can  lead  to  security  worries.  If 
you  install  software  on  your  mission-critical  system,  you  want  to  be  sure  that  it  does  not 
have  Trojan  horses  that  will  steal  or  corrupt  your  data.  The  people  who  write  the 
software  pose  an  “insider  threat,”  but  with  contemporary  component-software  integration 
practices,  there’s  a  very  wide  set  of  “insiders”  to  consider. 


1  Almost  everything  I  will  say  about  Java  applies  as  well  to  Microsoft’s  C#  (pronounced  C-sharp)  language. 
The  Java  language  is  used  to  write  programs  that  run  on  the  Java  Virtual  Machine  (JVM);  the  C#  language 
is  used  to  write  programs  that  run  on  the  Common  Language  Runtime  (CLR)  of  Microsoft’s  .Net  platform. 
JVM  and  CLR  can  run  on  conventional  operating  systems  such  as  Linux  and  Windows;  JVM  can  also  run 
directly  on  embedded  devices  such  as  smart  cards  and  cell  phones. 
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A  conventional  (and  very  reasonable)  solution  to  this  problem  is  to  use  protection 
mechanisms  so  that  less-trusted  software  components  have  limited  access  to  sensitive 
data.  In  the  past,  when  each  component  was  an  entire  software  application  that  ran  in  its 
own  address  space,  we  could  use  virtual  memory,  jointly  implemented  by  the  hardware 
and  the  operating  system,  as  such  a  protection  mechanism. 

But  virtual  memory  will  not  work  well  as  a  protection  mechanism  for  Java  components, 
because  the  more-trusted  and  less-trusted  components  all  share  the  same  address  space 
and  the  same  operating-system  process.  There  are  some  very  good  reasons  that 
components  share  an  address  space:  it  allows  the  interaction  between  components  to  use 
expressive  and  efficient  object-oriented  interfaces,  instead  of  clumsy  and  slow  remote 
procedure  calls  and  message  passing.  Therefore  virtual  memory  cannot  serve  as  the 
protection  mechanism. 

Java  has  a  built-in  protection  mechanism:  its  type-checker.  Java’s  type  system  enforces, 
in  the  source  code,  fine  grain  access  control  by  software  components.  Objects  of  one 
class  cannot  read  or  write  the  private  fields  of  objects  from  other  classes.  Java  source 
code  is  compiled  to  byte-codes  (called  “Java  Virtual  Machine  Language”,  or  JVML,  but  I 
will  just  use  “byte-codes”),  and  it  is  the  byte-codes  that  are  shipped  and  installed  on 
users’  JVMs,  but  the  byte-codes  are  also  type-checkable  by  the  byte-code  verifier  built 
into  the  JVM.  In  principle,  the  language-based  protection  built  into  Java  can  allow 
software  to  be  built  from  a  combination  of  less-trusted  and  more-trusted  components,  so 
that  less-trusted  components  have  limited  access  to  data  owned  by  more -trusted 
components. 

But  there’s  a  big  problem  with  language-based  protection  in  conventional  virtual 
machines  for  Java  and  C#.  What  if  the  protection  mechanism  has  holes  in  it?  That  is, 
what  if  bugs  in  the  implementation  of  the  virtual  machine  allow  the  less-trusted 
programmers  of  less-trusted  components  to  bypass  the  protection  and  access  private 
fields  of  more -trusted  components?  To  assess  this  problem,  we  examine  what  parts  of  a 
Java  Virtual  Machine  are  in  the  “trusted  base”  of  the  protection  mechanism.  The  trusted 
base  of  a  system  is  the  part  in  which  bugs  could  cause  security  vulnerabilities.  We  find 
[31]  that  the  trusted  base  of  a  conventional  JVM  is  huge,  comprising  hundreds  of 
thousands  of  lines  of  code.  One  of  the  biggest  problems  is  that  the  JVM  contains  a  just- 
in-time  (JIT)  compiler  that  translates  byte-codes  to  native  machine  code  (e.g.,  Intel 
Pentium  machine  language);  the  JIT  compiler  is  well  over  a  hundred  thousand  of  lines 
long  in  a  high-tech  JVM,  and,  as  I  will  describe,  a  bug  in  the  JIT  could  be  exploited  to 
breach  the  protection  mechanism.  It’s  not  realistically  possible  to  write  100,000  lines  of 
code  with  no  bugs  at  all,  so  we  cannot  rely  on  this  protection  mechanism. 

A  correct  JIT  compiler  guarantees  that  well-typed  byte  code  will  compile  to  machine 
code  that  respects  its  interfaces;  that  is,  the  machine  code  output  from  the  JIT  will  not 
access  private  fields  of  other  objects.  Bugs  in  the  JIT  compiler  can  be  exploited  by 
software  components  that  run  on  the  JVM  platform,  as  follows.  Consider  an  attacker 
who  is  providing  one  of  the  less-trusted  components  of  a  large  component-software 
system  written  in  Java.  Normally,  the  program  he  writes  will  never  be  given  access  to 


2 


private  data.  However,  suppose  the  unscrupulous  programmer  learns  of  a  bug  in  the  JIT 
compiler  that  causes  well-typed  byte-code  to  be  (incorrectly)  compiled  to  machine  code 
that  does  not  respect  its  interfaces.  He  writes  the  Java  source  code  for  his  component  to 
trigger  this  bug.  The  component  he  supplies  is  now  able  to  bypass  the  protection 
mechanism. 

This  is  a  pity,  because  Java’s  object-oriented  interfaces  and  language-based  security  lead 
to  significant  productivity  and  reliability  improvements  in  software  development,  and  if 
only  we  could  rely  on  its  language-based  protection  mechanism,  we  could  build  more- 
secure  systems  from  reusable  software  components. 


2.1  Research  goal  and  approach 

Thus  we  arrive  at  one  of  the  goals  of  our  DARPA-funded  research  project:  design  and 
prototype  an  architecture  in  which  the  language-based  protection  mechanism  is  provided 
by  a  JIT  compiler,  in  such  a  way  that  the  protection  mechanism  can  be  formally  verified. 
The  formal  verification  itself  should  be  believable,  that  is,  it  should  be  mechanically 
checkable  using  a  substantially  smaller  trusted  base  than  the  software  being  verified;  and 
the  verification  should  be  of  the  actual  software  that  is  installed  in  some  prototype 
system. 

We  had  several  reasons  to  believe  that  this  problem  could  be  successfully  approached 
using  formal  verification,  using  the  right  approach.  A  brute-force  approach  would  be  to 
formally  verily  all  the  Java  code  that  is  sent  to  the  JVM;  but  this  would  be  impossible, 
because  there’s  so  much  of  it,  and  it’s  written  by  programmers  who  don’t  have  the  time 
or  the  expertise  to  do  the  verification.  A  slightly  less  impossible  approach  would  be  to 
verify  the  correctness  of  the  JIT  compiler;  then  just  one  formal  verification  (of  the 
compiler)  could  be  leveraged  to  guarantee  safety  properties  of  all  the  unverified, 
untrusted  components  that  are  compiled  through  it.  But  still,  the  compiler  is  too  large  for 
current  formal-methods  techniques  to  work  well. 

The  approach  we  take  is  therefore  proof-carrying  code:  we  have  the  JIT  compiler  emit, 
along  with  the  native  machine  code,  evidence  that  the  code  is  safe  to  execute  (i.e.,  that  it 
respects  the  security  policy).  The  evidence  is  independently  checked  (and  compared  with 
the  code).  If  the  evidence  doesn’t  check  out,  or  fails  to  correspond  to  the  code,  then  the 
code  is  rejected  and  is  not  installed. 

This  crucially  relies  on  a  sound  logical  system  for  checking  the  evidence.  Soundness 
means,  “if  the  checker  accepts  the  evidence  for  the  claim,  then  the  claim  is  true.”  An 
important  part  of  our  research  has  been  to  demonstrate  the  soundness  of  our  system. 

This  setup  can  safely  tolerate  bugs  in  the  JIT  compiler.  A  bug  may  cause  the  code  to  be 
unsafe,  in  which  case  it  will  be  impossible  to  produce  evidence  that  the  checker  will 
accept;  or  a  bug  may  cause  the  evidence-generator  to  provide  bad  evidence,  in  which  case 
the  code  will  also  be  rejected.  In  the  worst  case,  a  bug  may  cause  the  compiler  to 
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produce  incorrect  but  safe  output  (machine  code  that  doesn’t  work  right,  but  at  least 
obeys  the  security  policy).  In  this  case,  it  is  possible  that  the  evidence  would  check  and 
that  the  code  could  be  installed  and  executed. 


2.2  Architecture  of  our  design 

The  major  components  of  our  solution  are  as  follows.  We  start  with  a  program  in  a  type- 
safe  source  language;  the  languages  we  have  prototyped  include  ML  and  Java. 

•  Framework,  type  systems,  and  algorithms  for  propagating  type-checking 
information  from  the  front  end  of  the  compiler  (Java  or  ML  source  code)  to  the 
middle  of  the  compiler  (intennediate  language(s)).  We  have  several  major  results 
in  this  area,  covered  in  technical  detail  by  several  of  our  publications. 
[1,8,9,10,11,19,21,23,24,28,29,44,52,53] 

•  Framework,  type  systems,  and  algorithms  for  propagating  type-checking 
information  from  the  middle  of  the  compiler  to  the  back  end  of  the  compiler 
(where  the  machine  code  is  produced);  we  have  several  major  results  on  this  topic 
[16,26,27,34,38,40,46,55] 

•  Design  of  a  language  for  communicating  “evidence”  from  the  compiler  to  the 
independent  checker.  [46,54,55,38] 

•  Soundness  proof:  A  fonnal  proof  that  if  the  “evidence”  is  accepted  by  the 
checker,  then  the  corresponding  machine  code  must  obey  the  safety  property. 

This  is  one  of  the  major  novel  results  of  our  research;  no  previous  proof-carrying 
code  system  had  such  a  proof.  Because  the  proof  is  so  large,  it  must  be  checked 
by  machine.  Thus,  this  part  of  the  research  involves  both  the  underlying 
mathematics  of  why  soundness  holds,  and  also  the  techniques  for  representing  this 
mathematics  in  a  machine-checkable  system. 
[3,4,5,7,12,14,17,18,20,36,45,50,56,58] 

•  Design  and  implementation  of  the  independent  checker  itself.  This  checker 
checks  two  things:  (1)  the  soundness  proof  for  the  evidence  language,  and  (2)  the 
evidence  for  safety  of  a  particular  program.  This  checker  is  the  “trusted  base”  of 
the  entire  system;  if  (and  only  if)  it  is  correct,  then  the  whole  system  can 
guarantee  enforcement  of  the  protection  mechanism.  Therefore  it’s  very 
important  that  the  checker  itself  be  small  and  simple  enough  that  it  can  be 
implemented  correctly.  Our  checker  is  small  and  simple:  it’s  about  1,100  lines  of 
C  code.  [30,54] 

We  can  make  quantitative  measurements  of  various  components.  The  SML/NJ  compiler 
from  ML  source  code  to  Sparc  machine  language  is  approximately  90  kloc  (thousand 
lines  of  code).  Thus,  for  a  conventional  compiler  the  implementation  effort  (where 
smaller  is  better)  was  90  kloc,  and  the  trusted  base  (where  smaller  is  better)  was  also  90 
kloc. 
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Our  new  proof-carrying-code  version  of  the  SML/NJ  compiler  is  approximately  114  kloc; 
that  is;  approximately  24  kloc  is  devoted  to  producing  the  “evidence”  for  the  checker. 

The  specification  of  the  “evidence  language”  is  5  kloc,  and  the  soundness  proof  is  about 
134  kloc.  Thus,  there  is  a  total  of  253  kloc  of  untrusted  code;  that  is,  a  bug  in  any  part  of 
that  code  would  not  lead  to  a  vulnerability,  because  if  it  caused  unsafety  it  would  be 
caught  by  the  checker.  We  have  a  trusted  base  of  3  kloc:  the  specification  of  the  safety 
policy  and  Sparc  machine  architecture  is  1.8  kloc,  and  the  checker  is  1.1  kloc. 

Overall,  the  project  has  been  successful,  not  only  at  demonstrating  the  applicability  of 
mechanized  formal  verification  to  the  assurance  of  protection  mechanisms  in  virtual 
machines,  but  also  to  the  measurement  of  how  large  a  task  it  is.  What  we  find  is  that,  in 
this  case,  formal  verification  reduces  the  trusted  base  by  a  factor  of  approximately  30, 
and  increases  the  development  effort  by  a  factor  of  approximately  3. 

Increasing  the  development  effort  by  a  factor  of  3  is  not  a  tradeoff  to  make  lightly.  We 
argue  that  for  a  highly  leveraged  piece  of  software  (such  as  the  virtual  machine  that  is 
used  as  platform  for  many  application  modules)  the  investment  may  be  worthwhile. 

2.3  Other  investigations  in  language-based  security 

In  addition  to  the  Foundational  Proof-Carrying  Code  project  described  in  the  previous 
subsection,  we  also  investigated  how  a  wider  class  of  security  policies  could  be  expressed 
using  techniques  that  go  beyond  ordinary  type  checking.  We  have  found  a  variety  of 
static  techniques  (that  can  analyze  programs  before  they  execute)  [12,  39,  48,  59]  and 
dynamic  techniques  (that  monitor  programs  as  they  execute)  [32,  49]. 

We  also  performed  an  experiment  to  question  the  very  assumptions  on  which  proof¬ 
carrying  code  (and  language-based  security)  is  based.  Our  soundness  proof  relies  upon 
the  assumption  that  the  computer  actually  executes  its  specified  instruction  set.  What  if 
the  attacker  tried  to  exploit  the  fact  that  sometimes  this  is  not  the  case?  In  particular,  it  is 
known  that  machines  sometimes  have  transient  memory  errors:  a  bit  in  memory  will 
change  its  value,  perhaps  because  a  cosmic  ray  passes  through  the  memory  chip.  This 
invalidates  our  assumption;  the  question  is,  could  an  attacker  actually  take  advantage  of 
this  to  breach  confidentiality  and  integrity  of  protected  data?  We  show  that  the  answer  is 
yes  [35];  one  can  design  a  Java  program  that  takes  advantage  of  random  memory  errors 
to  defeat  the  language-based  protection.  However,  we  also  show  that  conventional 
hardware  techniques  (parity,  or  single-error-correction-double-error-detection)  are 
adequate  to  restore  the  protection  guarantee. 

We  have  continued  investigations  into  whether  hardware  errors  could  compromise  in 
other  ways  the  assumptions  under  which  language-based  security  operates.  For  example, 
we  have  tried  attacks  suggested  by  recent  research  on  the  susceptibility  of  processors  to 
software-induced  voltage  swings  [Joseph  2003].  We  have  found  that  modern  commercial 
microprocessors  are  robust  against  such  attacks.  Overall,  our  conclusion  is  that  language- 
based  security  is  robust  with  respect  to  the  assumption  that  the  computer  hardware 
executes  its  instruction  set  as  specified,  but  that  this  issue  should  not  be  ignored. 
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3.  Proof-carrying  authentication  and  access  control 


Access  control  is  a  nontrivial  problem  even  in  a  single -host  system.  One  must 
authenticate  the  users  (that  is,  determine  whether  they  are  who  they  say  they  are)  and  then 
determine  whether  those  users  have  pennission  to  read  (or  write,  etc.)  the  given  data.  But 
in  a  distributed  setting,  the  problem  is  much  more  complicated.  There  are  many  different 
owners  of  data,  each  of  which  must  make  access-control  decisions  for  many  different 
(overlapping)  groups  of  users.  Different  data-owners  may  have  different  policies;  in  fact, 
they  may  have  different  languages  for  expressing  policies.  Some  parties  to  the  system 
play  specialized  roles  such  as  certifying  the  association  of  authentication  keys  to  users. 

Previous  work  on  distributed  authentication  logics  [Lampson  1992]  and  on  public-key 
infrastructures  [Housley  2002,  Ellison  1999]  has  given  us  a  useful  framework  for 
thinking  about  the  problem,  but  each  of  these  works  assumes  that  there  is  just  one 
language  for  expressing  policies — and,  of  course,  each  work  has  its  own  different  idea  of 
what  that  language  should  be. 


3.1  A  distributed  authentication  framework 

The  problem  we  set  out  to  solve  is  this:  build  a  framework  for  specifying  and 
implementing  languages  for  distributed  authentication/authorization  frameworks,  so  that 
different  languages  (even  ones  yet  to  be  invented)  can  interoperate  soundly,  and  so  that 
expressive  languages  can  be  designed  for  application-specific  purposes. 

The  approach  we  take  is  this:  for  each  policy  language,  define  its  operators  using  formal 
logic.  (The  user  of  the  language  won’t  have  to  see  the  fonnal  logic.)  Then  use  these 
definitions  to  prove  the  soundness  of  each  policy  language  individually.  Because  each 
language  is  definitionally  specified  in  the  same  underlying  logic,  they  can  then  soundly 
interoperate,  not  only  with  each  other,  but  with  policy  languages  yet  to  be  invented.  [2, 

13] 

Our  system  relies  on  machine-checked  formal  proof,  just  as  our  proof-carrying  code 
system  does.  We  use  the  same  logical  infrastructure  as  in  PCC,  and  the  same  proof- 
development  tools.  In  fact,  the  same  (small  and  simple)  independent  checker  that  we 
used  for  PCC  can  also  be  used  for  proof-carrying  authentication. 

We  built  the  framework,  and  to  demonstrate  its  effectiveness  we  used  it  to  implement  a 
distributed  access-control  policy  language.  The  prototype  language  has  features  such  as 
certificates,  local  names,  general  delegation,  specific  delegation,  and  time-dependent 
policies.  We  show  how  it  can  be  easily  extended  to  do  expiration,  key  management  and 
revocation,  abstract  principals,  and  delegation  across  domains. 

We  interfaced  our  implementation  to  the  Apache  web  server  and  to  a  proxy  web  client, 
and  we  showed  that  it  is  useful  in  practice  in  fine-grain  access  control  to  web  pages  on 
the  Internet.  [60,  37] 
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3.2  Proof-carrying  linking 


Another  application  of  proof-carrying  authentication  is  the  specification  and  checking  of 
software  component  assemblies. 

Large  software  systems  are  often  built  from  loosely  coupled  subsystems.  When  a 
software  integrator  uses  a  third-party  software  component  as  a  building  block  in  a  system, 
he  doesn’t  want  the  code  he  imports  to  break  the  whole  system.  How  can  he  detennine 
that  it  is  safe  to  link  the  foreign  software  component  into  the  system? 

The  most  widely  used  methods  for  ensuring  safe  linking  are  type  checking  and  code 
signing.  Type-checking  can  make  some  very  strong  guarantees  of  some  security 
policies — it  is  the  basis  of  the  our  PCC  research,  for  example;  but  we  also  wanted  to 
explore  how  code  signing  could  be  used  in  a  principled  way.  Code  signing  ensures  that 
someone  trustworthy  trusts  the  code,  but  it  is  not  always  enough  for  guaranteeing  system 
safety  since  trusted  software  companies  or  software  developers  unintentionally  make 
mistakes.  Software  signed  by  trusted  companies  can  still  cause  security  holes  in  users' 
systems.  For  example,  in  November  2002  Microsoft  released  a  badly  coded  ActiveX 
control,  signed  (as  usual)  with  Microsoft's  code-signing  key;  the  bug  led  to  a  security 
vulnerability.  Because  Microsoft's  code-signing  protocol  is  insufficiently  expressive, 
Microsoft  was  faced  with  the  choice  of  setting  a  kill  bit  so  that  no  browser  would  run  the 
control — thereby  disabling  thousands  of  websites,  even  ones  containing  no  security- 
critical  data— or  not  setting  the  bit — thereby  continuing  to  endorse  the  product. 

Microsoft  chose  the  latter;  it  recommended  that  users  who  desired  a  secure  system  should 
remove  Microsoft  from  Internet  Explorer's  Trusted  Publisher  List  [Microsoft  2002], 

We  designed  and  prototyped  Secure  Linking  (SL)  [33,  42],  a  flexible  way  of  allowing 
software  component  users  to  specify  their  security  policy  at  link  time,  giving  the  users 
more  control  than  type-checking  or  traditional  digital  signing.  Our  Secure  Linking 
mechanism  would  not  prevent  bugs  in  ActiveX  in  the  previous  example,  but  it  would 
give  the  software  provider  and  the  software  consumer  finer-grained  control  of  the 
meaning  of  certificates  they  use. 

With  the  SL  framework,  a  code  consumer  can  establish  a  linking  policy  to  protect  itself 
from  malicious  code  from  outside.  The  policy  can  include  certain  properties  that  the  code 
consumer  thinks  useful  for  system  safety:  software  component  names,  application- 
specific  correctness  properties,  version  information  of  software  components,  and  so  on. 

To  link  and  to  execute  a  component  in  a  SL-enabled  system  there  must  be  a  machine- 
checkable  proof  that  the  component  has  the  properties  specified  in  the  code  consumer’s 
linking  policy.  This  proof  might  be  provided  by  the  code  provider,  or  might  be  produced 
by  an  untrusted  proving  algorithm  that  runs  on  the  code  consumer's  machine.  The  proof  is 
formed  using  the  logic  and  inference  rules  of  the  framework.  After  being  submitted,  the 
proof  is  checked  by  a  small  trusted  proof  checker  in  the  code  consumer,  and  if  verified, 
the  component  is  allowed  to  be  linked  to  other  components  in  the  code  consumer. 
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Just  as  our  proof-carrying  authentication/authorization  framework  is  designed  to 
accommodate  many  different  policy  languages,  so  is  our  SL  framework.  We  tested  this 
aspect  of  SL  by  showing  that  Microsoft’s  “package  assembly”  language,  for  specifying 
linking  policies  in  their  .Net  framework,  can  be  encoded  in  SL  and  interoperate  with 
other  policy  languages. 


4.  Information  assurance  measurement 
(policy-based  network  management) 


In  early  2003,  we  began  a  seedling  project  to  investigate  whether  mechanized  logical 
reasoning  could  be  helpful  in  dealing  with  the  complexities  of  network  management,  with 
firewalls,  routers,  server  software,  CERT  advisories,  and  so  on.  We  have  made 
substantial  progress  on  this  effort,  leading  to  a  significant  research  result  in  November 
2004,  a  few  months  after  the  end  of  the  DARPA  contract  [61]. 

To  determine  the  security  impact  that  software  vulnerabilities  have  on  a  particular 
network,  one  must  consider  interactions  among  multiple  vulnerabilities  and  multiple 
hosts.  We  implanted  a  tool  called  MulVAL,  an  end-to-end  framework  and  reasoning 
system  that  conducts  multihost,  multistage  vulnerability  analysis  on  a  network.  MulVAL 
is  cleanly  modularized  so  that  it  can  effectively  leverage  existing  work  on  single-host 
vulnerability  recognition  and  network  configuration  management.  The  reasoning  engine 
in  MulVAL  takes  inputs  from  off-the-shelf  tools  [Wojcik  2003]  and  performs  analysis  on 
the  whole  network  to  determine  if  vulnerabilities  found  on  individual  hosts  can  result  in  a 
condition  violating  a  given  high-level  security  policy.  MulVAL  considers  interaction 
among  multiple  hosts  and  multiple  vulnerabilities,  as  well  as  network  and  machine 
configurations  that  are  relevant  in  attacks.  In  the  wake  of  a  new  vulnerability  report, 
MulVAL  can  quickly  tell  a  system  administrator  if  the  new  bug  breaks  the  security  policy 
of  the  network.  If  so,  MulVAL  generates  an  attack  trace  to  help  the  system  administrator 
decide  upon  countenneasures. 


5.  Technology  transfer 

Our  research  can  be  most  useful  to  DARPA  and  its  clients  if  our  technology  can  be 
transitioned  into  industrially  useful  tools.  We  have  actively  sought  avenues  for 
technology  transfer. 

Our  proof-carrying  code  research  shows  how  to  build  more-secure,  higher-assurance 
virtual  machine  platforms  for  languages  such  as  Java  and  C#.  The  natural  technology 
transfer  path  is  to  have  the  commercial  builders  of  such  platforms  leam  how  to  adopt  this 
technology.  Then,  as  a  matter  of  course,  any  existing  or  new  Java  or  C#  applications  can 
and  will  be  run  on  more-secure  platforms.  For  the  Java  platform,  we  have  collaborated 
since  2001  with  Intel  Research,  who  make  open-source  Java  and  .Net  research  virtual 
machines.  They  have  been  incorporating  some  of  the  evidence-generation  technology  in 
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their  JIT  compiler.  We  have  also  worked  informally  with  researchers  at  Microsoft  who 
are  constructing  their  next-generation  virtual  machine  for  the  .Net  platform.  In  fact,  the 
graduate  student  who  built  our  certifying  compiler  back  end  [55]  is  now  working  on 
similar  projects  at  Microsoft  research. 

The  technology  transfer  for  proof-carrying  authorization  is  being  done  in  a  different  way. 
The  student  who  built  our  PCA  system  [37]  is  now  a  research  scientist  working  on  a 
project  led  by  Michael  Reiter  at  CMU  to  build  PCA  into  smart  cards  for  a  distributed 
access-control  system.  This  project  should  demonstrate  whether  PCA  can  be  successful 
in  demanding  circumstances. 

We  are  planning  to  do  technology  transfer  of  policy-based  network  management  based  on 
a  collaboration  with  HP  Laboratories.  We  have  been  discussing  this  with  them  for 
several  months  and  serious  work  on  a  joint  project  is  likely  to  begin  in  early  2005. 
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